The invention is related to Internet Protocol (IP) telephony systems. More specifically, the invention is related to systems and methods for routing the data packets that carry communications enabled by an IP telephony system, such as telephone calls and text or video messages.
Existing IP telephony systems allow users to place and receive telephone calls or to send and/or receive other types of communications, such as text messages, SMS messages, MMS messages and the like. The communications are transmitted, at least in part, by data packets that traverse a private and/or public data network.
For example, a calling party can place a telephone call to a called party using an IP telephony device that is coupled to a private or public data network. When the user requests that the call be placed, an IP telephony system receives the request and sets up the call between the calling party's telephony device and the called party's telephony device. The called party's telephony device can also be an IP telephony device that is coupled to a private or public data network. Alternatively, the called party's telephony device could be an analog telephone that is coupled to a publicly switched telephony network (PSTN). In still other instances, the called party's telephony device could be a cellular telephone or a mobile computing device with cellular telephone capabilities that is coupled to a cellular telephony network.
Typically, an IP telephony system receives a call setup request from the calling party's telephony device at an inbound proxy server (or an originating gateway). The inbound proxy server consults a routing engine to determine how to setup the telephone call to the called party's telephony device.
If the called party's telephony device is another IP telephony device coupled to a data network, this would typically mean determining the identity of another server that can deliver data packets to the called party's IP telephony device. The server that is capable of delivering data packets to the called party's IP telephony device may be referred to as a destination Proxy Server or Session Border Controller (SBC).
If the called party's telephony device is an analog telephone coupled to a PSTN or a cellular telephone coupled to a cellular telephone network, this would typically mean determining the identity of a destination gateway that is capable of interacting with the relevant PSTN or cellular telephone network. In this instance, the IP telephony system would deliver data packets bearing the media of the telephone call to the PSTN or cellular telephone network, and the PSTN or cellular telephone network would convert the data packets into appropriate signals, and then send those signals to the called party's telephony device.
The quality of a telephone call, or any other type of communication carried in this fashion, is highly dependent on how well the data packets carrying the media of the telephone call are being transmitted over the relevant private and/or public data networks. If data packets are being lost, call quality will deteriorate. If transmitted data packets are being significantly delayed, call quality will deteriorate. Another problem is jitter, where the latency or delay is variable in nature. If jitter becomes a problem, call quality also will deteriorate.
Presently, IP telephony systems have only limited control over the physical path that the data packets bearing the media of a telephone call travel as they pass over public and private data networks. In some cases, the only aspect that can be controlled is the identity of the inbound and outbound gateways, Session Border Controllers, or media servers.
For these reasons, some IP telephony systems track the quality of data transmissions passing through the inbound and outbound gateways, SBCs, or media severs that it routinely uses to transmit data communications. This can be accomplished by periodically conducting testing to determine data packet transmission statistics for data packet transmissions passing through individual gateways or servers. As noted above, the data packet transmission statistics can include delay, packet loss, jitter, and other measures. The results of such testing is correlated in databases which provide information on the relative quality provided by each of the gateways or servers.
When a new call setup request is received at an inbound proxy server of an IP telephony system, the inbound proxy server consults a routing engine to determine the best outbound gateway or server to use to complete the call to the called party's telephony device. If multiple outbound gateways or servers are capable of completing the call, the routing engine typically takes the call quality provided by each of the outbound gateways or servers into account when determining which outbound gateway or server to recommend to the inbound proxy server.
Databases indicating the call quality provided by various gateways or servers are necessarily based on historical data which has been collected over an extended period of time. As a result, the historical databases are really a prediction of the likely call quality that the various gateways or servers can presently provide, based on how well the gateways or servers performed in the past. But there is no guarantee that a gateway or server that performed well in the past will perform well for a new call that is just being setup.
Moreover, the data packets that carry the communications between a calling party's telephony device and a called party's telephony device may traverse multiple private and/or public data networks. For example, a call established between a calling party's IP telephony device and a called party's analog telephone might traverse three separate data networks.
During a first hop, the data packets would traverse the public Internet between the calling party's IP telephony device and the inbound gateway or media server of the IP telephony system. The traversal of the public Internet could itself involve multiple separate hops between various nodes of the public Internet. Two consecutive data packets generated by the calling party's telephony device could traverse vastly different paths as they make their way between the calling party's telephony device and the inbound gateway or media server of the IP telephony system.
During a second hop, the data packets could traverse a private data network maintained by the IP telephony system as the data packets travel between the inbound gateway or media server and the outbound gateway or media server. In other instances, the inbound gateway or media server may be controlled by the IP telephony system, and the outbound gateway or media server could be operated and controlled by a separate partner service provider. In that instance, the IP telephony system will likely route the data packets from the inbound gateway or media server to the outbound gateway, SBC, or media server (maintained by the partner service provider) over the public Internet. Here again, this would likely involve multiple separate hops between different nodes of the public Internet.
If the call is directed to a called party's analog telephone that is connected to a PSTN, the outbound gateway or media server would deliver the data packets to the PSTN. But the PSTN itself might carry the call as data packets through a private data network until the data packets arrive at a gateway or server that is located near the called party's analog telephone. At that point, the data packets would be converted into analog signals that are transmitted to the called party's analog telephone over the PSTN. Thus, the data packets may also be carried over a private data network maintained by the PSTN. This same basic process also occurs if the called party's telephony device is provided with service from a second IP telephony system.
The multiple hops along all these various transmission devices can lead to significant transmission delays that negatively affect call quality. Also, when so many different devices are responsible for the delivery of the data packets, there are many potential sources of error which can result in delay, lost packets, and problems with jitter. And, as noted above, with the present system of routing telephone calls, about the only aspect that the IP telephony system can control is the quality of the transmission path between the inbound gateway or media server and the outbound gateway or media server. Further, even that control is exerted using only historical call quality data that provides no guarantee that the inbound and outbound gateways or media servers selected for a new call will provide the same call quality for the new call as they did for previous calls.
In an attempt to address the above-discussed problems a new Voice over Internet Protocol routing specification has been developed that provides greater control over how data packets bearing the media of an IP telephone call are routed between a calling party's telephony device and a called party's telephony device. The new specification, which is called Interactive Connectivity Establishment (ICE) is explained in detail in IETF RFC 5245, by Jonathan Rosenberg, published Apr. 1, 2010, the contents of which are hereby incorporated by reference.
When the ICE specification is used to route an IP telephone call, the signaling that sets up the call still traverses the lengthy, multiple hop path described above. However, the ICE specification makes it possible to route the data packets bearing the media of the telephone call in a more direct and controlled fashion. Under the ICE method, the calling party's telephony device and the called party's telephony device communicate with one another during call setup to determine the best way to route data packets between each other. During this process, each of the telephony devices will compile a list of media relays that could be used to route data packets to and from itself. The calling party's telephony device sends its candidate list to the calling party's telephony device, and vice versa.
Each telephony device then creates a list of candidate pairs that could be used to communicate data packets between the calling party's telephony device and the called party's telephony device. Each pair includes one candidate from the calling party's list and one candidate from the called party's list. The candidate pairs are ranked based upon some ranking scheme that is intended to predict which candidate pairs will likely result the best communications. Note, these rankings are not based upon any real world or real-time testing. The rankings are simply based upon a predetermined rules that attempt to predict which candidate pairs will provide the best communication paths.
At least one of the telephony devices will then attempt to send a message to the other telephony device using the highest ranked candidate pair on the list. If the message is received by the other telephony device, it sends back a response. The telephony devices start with the highest ranked candidate pairs. And as soon as one of the candidate pairs succeeds in providing a communication path in both directions, the telephony devices will use that candidate pair to communicate data packets bearing the media of the telephone call. If the highest ranked candidate pair fails to provide an effective two-way path between the telephony devices, the telephony devices move on to the next-highest ranked candidate pair.
While the ICE specification ensures that the pair of media relays that is initially used to route data packets between a calling party's telephony device and a called party's telephony device will be operable, there is no guarantee that the selected pair of media relays will provide high call quality. As noted above, no real time or real world testing is performed to verify which of the candidate pairs will provide the best quality. Instead, the rankings are only based upon predicative predetermined rules. Also, the first candidate pair that provides two way communications is used as the path for the call. This means that if the first candidate pair works, but provides poor call quality, and the second candidate pair on the list would have provided excellent call quality, the call will still be established over the lower quality path between the first candidate pair.